GRACE TECHNICAL REPORTS
Common Criteria
に特化したセキュリティ要求分
析方法論の提案
飛田孝幸
,
金子浩之
,
田口研治
,
吉岡信和
GRACE-TR 2009–05
2009
年
9
月
24
日
CENTER FOR GLOBAL RESEARCH IN
Common Criteria
に特化したセキュリティ要求
分析方法論の提案
飛田孝幸
,
金子浩之
みずほ情報総研株式会社
情報セキュリティ評価室
{takayuki.tobita,hiroyuki.kaneko}@gene.mizuho-ir.co.jp
田口研治
,
吉岡信和
国立情報学研究所
GRACE
センター
{ktaguchi,nobukazu}@nii.ac.jp
2009
年
9
月
24
日
概 要
セキュリティ要件をシステム開発の上流工程において獲得、モ デル化することは、下流において発見される可能性のある、システ ムの脆弱性をより少なくするための開発指標として広く認知されて いる。そのような方法論をシステム開発において用いることは、脆 弱性の少ないシステムを開発するためにも重要であり、特にセキュ リティ評価の国際標準であるCommon Criteria (CC)における要件 定義書であるSecurity Target (ST)を作成する際に非常に有益であ る。これまでにも要求工学においてはKAOSやi*を用いたセキュ リティ要件の獲得・モデル化方法が提案されていたが、産業界にお いて広く利用されてはいない。その理由としては、従来の開発プロ セスとそれらの方法論のミスマッチや、基礎となる意味論などが複 雑なので、学習コストが非常に高いことなどが挙げられる。システ
ム開発における標準的な設計言語であるUMLはシステム要件の獲
得のためにユースケース図を提供している。これをセキュリティ要 件獲得のために拡張したものにミスユースケース図がある。本図法 はユースケース図に攻撃者や脅威、それに対する対抗策を明示的に モデル化を可能する拡張を加えたものである。本図法は、上記の２ 点の問題点をクリアしており、産業界において有効に利用すること
が可能である。しかし、CCへの適用を考えると、必要なモデル化
要素が欠けており、必ずしも直接的に適用が可能では無い、という 欠点がある。
本技術レポートでは、CCとの関連において、セキュリティ要件
の獲得・分析を行うためのセキュリティ要求分析方法論をミスユー
スケース図を拡張することで提案するものである。まず、STのメ
タモデルを記述し、そのメタモデルを忠実に解釈することが可能な
ミスユースケース図をUMLの拡張機能を用いて定義する。このこ
て、メタモデルのどの部分をモデル化するかを段階的に獲得するプ ロセスを提案する。ケーススタディとして、多機能プリンタ（Multi Function Pheripheral）を用いて、本方法論におけるモデル化の方
法とそのプロセスを示す。
1
はじめに
今日、情報システムの開発において、セキュリティを考慮するのは必須 の条件である。毎日のように様々な情報システムにおいて、脆弱性が発見 されており、そのための緊急パッチを当てるなどの対処法を取るのは不可 欠になっている。このような状況を生む原因の一つは、情報システムの 開発プロセスにおいて、セキュリティを考慮した開発手段が利用されてい ないことが、一つの大きな理由として挙げることが出来る。特に、セキュ リティに関連する要件と、それをどのような機能として実現するかにつ いて、要求獲得・分析フェーズにおいて十全な分析が行われない傾向があ り、それがセキュリティに対する様々な対処を遅らせる原因の一つになっ ている。
要求工学においては、様々な方法論がセキュリティ要件の分析・獲得に 関連して提案されている。しかし、実際の開発現場においては、必ずしも 利用されていないのが現状である。利用されていない理由の一つとして は、提案されている方法論が実際の開発現場において利用されているもの とは、大きく異なる点がある。既存の開発プロセス・開発方法論を変更す るのは、非常にコストがかかるので、実際に開発現場において利用されて いる開発プロセスにおいて直接利用することが困難な場合、往々にして開 発現場において受け入れられないのが現状である。それに対して、一般的 に言うと、従来利用されているものを拡張、改良したものについては受け 入れやすいという傾向がある。そのような点を考慮して、本論文において は、システム開発において広く利用されている UML (Unified Modeling Language)におけるユースケース図を拡張したセキュリティの要求分析・ 獲得方法論を提案する。
は様々なIT製品が認証されているが、実際のそれらのIT製品の開発に おいては、必ずしもセキュリティに関する要件を要求分析工程において獲 得・分析している訳ではない。多くのIT製品においては、CCによる認 証を行うために初めて、STとしてセキュリティ要件を整理、定義してい るのが製品開発の現状である。セキュアな製品開発のためには、セキュリ ティ要件の獲得を、他の機能要件の獲得と同時に行い、セキュリティに関 する様々な要件定義を後から行う、といった製品に脆弱性をもたらすこと が無い開発プロセスを導入すべきである。さらにSTの作成は、想定する セキュリティ上の課題とそれに対する対策の対応管理が困難であること、 及び記述内容の他者との共有が困難であることが課題となっており、開発 者がCC取得を敬遠する一因となっている。
本技術レポートでは、我々が開発した CC をターゲットとしたセキュ リティ要求分析方法論について説明を行う。本方法論は、基本的なモデリ ング方法論として、開発現場において広く利用されているUML (Unified Modeling Language) におけるユースケース図を拡張したものを用いる。 その拡張においては、CCを意識した様々な工夫がなされている。UML を用いる利点としては、開発現場において広く利用されているので、再教 育のコストが少ない点や、その拡張可能な柔軟性、様々な図表現を用いて 環境、機能要件、静的・動的なシステム要件などの記述が出来る点、視覚 的に理解し易い点を上げることが出来る。ユースケース図は、要求獲得 フェーズにおいて、システムの機能的な要件を分析する際に用いられてお り、開発対象の範囲、システムを利用するアクター、システムの提供する 機能を表すユースケース、それらの間を接続する関連（association）リン クにより成り立っている。ユースケース図をセキュリティの分析に用いら れるようになったのは、McDermottらによるアビューズケース図[6]や、 Sindre らによるミスユースケース図[9] を嚆矢とする。これらの研究と の比較は、第５章において行われる。我々の提案するミスユースケース図 と STとの対応の妥当性を示すために、STにおけるモデル要素の UML プロファイルを示し、どのように示されたモデル要素が分析・獲得される かを示す。さらに、事例に適用することで、その表現方法が効率的である か、有効であるかを示す。
図1: ユースケース図の例
行い、最後に第６章において本論文の結論について述べる。
2
関連技術
2.1
ユースケース図
ユースケース図は、システムが持ちうる機能に関してアクター(actor) と呼ばれるユーザとシステムのやりとりを図示したものである（図1）。 ユースケース図は機能要求を把握する手法として、専門用語等は用いず、 顧客であるエンドユーザやその分野の専門家に分かり易く記述される。
ユースケース図（Use case Diagram）には、セキュリティに特化した 様々な拡張が存在する。SindreとOpdahl[9]によるミスユースケース図 （Misuse case Diagram）においては、通常のアクターに加えて故意もし くは、意図せずにシステムに害を加えるミスユーザ（misuser）と、それ による脅威（ミスユース）を明示的にモデル化することが出来る。ここで は、ミスユースケース図のメタモデル（図2）と、その例を示す（図 3）。
2.2
コモンクライテリア
図2: ミスユースケース図のメタモデル
図3: ミスユースケース図の例
ティ機能を含む）を開発する場合、その開発した部分の信頼性が保証され ていることを評価するための国際標準がCCである。特に、ITに関する 明確なセキュリティ要求が存在し、その要件を満たす機能を実現する主体 （開発者）が明確である場合、ここにターゲットを絞ってセキュリティ要 求が満たされることを、その主体が保証したい場合に、CCの適用効果が 高まる。
CCの規格文書は３つのパートで構成されている。
• パート１：概説と一般モデル 評価対象（TOE：Target of Evaluation） と運用環境を正確にモデル化し、資産（Asset）、脅威（Threat）及 び対抗策（Objective）によるセキュリティの概念と関係に基づいて、 TOEの機能要件（Functional Requirement）と保証要件（Assurance Requirement）に関する評価の枠組みをセキュリティターゲット（ST： Security Target）として定義すること、及びSTに基づくTOE評 価の一般モデル
• パート２：セキュリティ機能コンポーネント セキュリティ機能要 件の全体像（パラダイム）、11のクラスからなる機能要件のカタロ グ情報
• パート３：セキュリティ保証コンポーネント セキュリティ保証の アプローチに関する全体像（パラダイム）、評価保証レベル（EAL： Evaluation Assurance Level）の定義、STやプロテクションプロファ イル（PP：Protection Profile。特定の製品種別に対するセキュリティ ニーズについて、実装に依存せず、STの雛形として用いることが できる構成でまとめた文書）を含む8クラスからなる保証要件のカ タログ情報
また、CCに基づく評価方法論を示すCEM（Common methodology for Information Technology Security Evaluation）と呼ばれる規格文書があ る。CEMは、CCパート３の各保証要件に対して、評価者が実施すべき 評価アクションを具体的に示したものである。評価者は、STで定義され た評価保証レベルの保証コンポーネントに対し、CEMに定義されるより 詳細な評価単位であるワークユニット毎に評価を行う。
2.3
コモンクライテリアに基づく保証と評価
求を満たすセキュリティ機能性やセキュリティ保証に関する信頼性の確 保を求めるために、各国でITセキュリティに関する第三者による評価・ 認証制度の整備が進んでいる。日本では「ITセキュリティ評価及び認証 制度」（JISEC：Japan Information Technology Security Evaluation and Certification Scheme）が運用される。また、各国の評価・認証制度で取 得したCC認証を認め合うCC相互承認協定（CCRA：CC Recognition Arrangement）により、自国認証以外の幅広いCC認証済み製品の国際相 互流通を可能としている。CC認証済み製品としては、OS、DBMS、ファ イアウォール、ネットワークコンポーネント、データ保護、アクセス制御、 認証などのメカニズムを提供するコンポーネント、スマートカード、セ キュリティを重視するLSIなど、多くの分野の1000を超える製品が各国 認証制度のWebサイト等でリストされている．これらの分野の主要製品 の多くは、既にCC評価・認証を取得している。なお、評価者は、セキュ リティ保証の実務に関する豊富な経験と評価ノウハウを有し、かつ制度か ら認められた組織（認定された評価機関）に属し、中立公平な第三者の立 場から、設計評価、試験評価、侵入検査などを含むセキュリティの評価を 実施する。
ここでは、CCに基づいた評価を受ける製品開発者から見た典型的なCC の適用例を示す。CCやCEMの規格文書は、評価を行う側の視点で記述 されている。また、パート２セキュリティ機能要件やパート３セキュリ ティ保証要件の規定は、開発者の通常の理解よりも抽象的な表現で示され ている。そこで、製品開発者は、CCやCEMの規定を開発者側への要求 事項として読み替え、対象製品へのCC適用を行う場合の具体的な実施事 項を検討し、CCに基づく保証の対応方針を明らかにする。その上で、以 下に示すアプローチで、製品セキュリティの特性と構造の記述を、自然言 語でSTとして作成することから開始する。
(1) 利用者視点で製品に求められるセキュリティ要求を収集整理する。 適用すべきPPがあれば、その内容を分析する。そのほか、製品戦略上、 重要と位置付けたセキュリティ要求についても検討する。これらを踏ま え、製品セキュリティのコンセプトを定義する。
(2) 評価の効果と保証の実施可能性を踏まえ、評価対象の範囲とEAL を定める。
(3)保護対象とする資産に関する脅威モデルを定義・分析し、想定する 特定の運用環境における対抗策を定義する。定義した脅威と対抗策の関係 は、この製品を採用する利用者が納得できる論理構造となっていることを 確認する。
(5)機能要件を評価対象においてどのような機能として実現するかの要 約を仕様化する
(6)これらの検討結果を踏まえ、図4にあるST文書の構造通りに記述 する。
STを作成したのち、EALの定義にしたがった個々の保証コンポーネン ト（開発、ガイダンス文書、ライフサイクルサポート、テストの各クラス のうち、設定されたEALで満たすべき保証コンポーネント。図 5にCC パート３で定義する保証コンポーネントの構成を示す）が要求する評価エ ビデンスや、評価者がセキュリティ機能のテストや侵入検査を実施するた めのテスト環境を準備する。脆弱性評定クラスに対しては、開発者が準備 するエビデンスはテスト環境以外に存在しない。ただし、EALのすべて の保証コンポーネントを満たすことを主張するためには、評価を受ける前 に、顕在化する脆弱性が存在しないことを確認しておく必要がある。具体 的には、最初に評価対象の動作に影響を与える公知の脆弱性情報を収集す る。次に、評価対象の仕様や設計・開発の過程で脆弱性が組み込まれる可 能性がある部分を洗い出し、これらの脆弱性が評価対象において対策済み であることを確認する。また、必要に応じて脆弱性の残存有無を確認する ために、開発者自身による侵入検査を実施することが望ましい。
このように、STをはじめ、評価エビデンスの最終内容は、ライフサイ クルサポートの一部のエビデンスを除き、開発が完了し出荷対象となる TOEを対象とした、完成されたものである必要がある。CCの評価にお いては、セキュリティの要求獲得・記述・分析フェーズのエビデンスは求 められない。一方、製品の導入を検討する利用者は、その利用者のニー ズに合った製品構成であり、意図する使い方が可能かどうかの確認のみで なく、ある特定の脅威への対抗策を具備しているかなど、個別のセキュリ ティ要求についても確認するかもしれない。また、利用者の想定する運用 環境において、その製品がこれらのセキュリティ要求を満たすことが検証 済みであることを期待するかもしれない。これらの確認は、STを拠り所 として行われることから、STを作成する際には、利用者の検討候補とな り得る評価対象の構成や、想定する運用環境に合致した検証環境を特定す ることが不可欠である。CC評価では、STに定義された内容が、その製 品の導入を検討する利用者からみて、評価範囲や評価したセキュリティ機 能について誤解を生じることがない記述かどうかの観点からも検査する。
3
セキュリティ保証における課題
図4: STの構造
図5: EALと保証コンポーネントの相互参照（CCパート３より）
3.1
CC
導入段階
CCの導入段階では、開発者は初めてSTを作成することが多く、STの 定義内容の内部一貫性の欠如や、開発エビデンスとの対応の不整合が起こ りやすい。CCは図4のSTの構造と記述内容を規定しており、TOEで扱 う脅威、対策、セキュリティ要件について、論理矛盾のない識別単位で構 成し、それぞれの構成要素の簡潔明快な説明（CCではステートメントと 呼ぶ）、及び完全性、正当性に関する根拠を自然言語で記述することを求 めている。ただし、CCはSTを作成するための元となる要求分析や脅威 分析の手法を定めていない。また、評価すべき対象とするセキュリティ要 件について、PPや市場要求を踏まえ、要件の取捨選択等の現実的な調整 が必要となる。しかしながら、実際には、開発者は、製品の仕様要求、セ キュリティ要求、及びCCで評価するセキュリティ要求間の対応関係や論 理構造を分析・管理・共有する手段を持たないケースが多い。これがST 定義の不整合や、ST作者以外の設計者が担当する開発エビデンスの対応 不整合の原因となる。
3.2
要求工学的アプローチのセキュリティ保証への適用の方向性
ティ要求分析がどのように適用されるべきかについての方向性を以下に 示す。
3.2.1 CCに最適化した要求のモデリング方法論とすること
CCではSTに基づいて保証を主張することが原則であることから、CC のセキュリティ構造とモデルの構造との対応関係、及び表現における親和 性は必須要件である。TOEが満たすべきセキュリティ要件は、保護すべ き資産と脅威の関係をベースとしたモデル化が必要である。ただし、ST は設計書ではなく評価のための定義書である。CCに基づいて評価できる ことが重要であり、セキュリティ要求仕様の全体と完全に一致する必要は ない。一方、利用者が自身の要求を満たすことが確認できるレベルの正確 なステートメント表現が求められ、ST上の識別ラベルを使って表現でき ると分析の効率性が高まる。また、モデリング方法論は、開発エビデンス との対応関係を維持するために、製品仕様の分析モデルと相互参照可能で あると開発エビデンスとの対応が取りやすくCCの適用のトータルコスト が削減できる。
3.2.2 製品開発現場での導入に負担が少ないこと
要求分析の方法論は、過度なコストをかけることなく製品開発現場に 導入できる必要がある。ここでのコストとは、方法論の理解・習得にかか る教育コスト、方法論を実現するサポートツールの操作性、コミュニケー ションやネゴシエーションに要する総時間、製品設計・開発に対するイン パクト（効果または負担）に伴うコスト、知識移転に要するコストなどを 想定する。
3.2.3 要求管理が製品ライフサイクル全体で維持可能であること
図 6: CCによるセキュリティ保証の課題と要求工学的アプローチの適用 要件
4
セキュリティ要求分析方法論
CCとの親和性を意識したモデリング手法として、UML（Unified Mod-eling Language）を拡張する場合の例を示す。UMLを用いる利点として は、開発現場において既に広く利用されているため、導入コストがかから ないこと、拡張に対して柔軟性を持ち、かつ視覚的にも理解しやすく、分 析におけるコミュニケーションが容易であることが挙げられる。このモデ リング手法により製品のもつセキュリティ機能（function）と資産（asset） の観点からそれに対する脅威と対策を分析し、明示的にモデル化すること が可能となる。
4.1
従来のユースケース図との親和性
従来のユースケース図の構成要素は、利用者や管理者等のアクター（ ac-tor）と関連するユースケースであるが、特定のシステムについてのユー スケース図には、以下が潜在的に存在するはずである。
• ユースケースで取り扱われるデータ（data）
• ユースケースを提供する機能（function）
ここでは、それらの要素を用いて、特定のシステム（または製品）のセ キュリティ機能の妥当性について分析することを考える。システムまたは 製品のユースケース図では、ユースケースを提供するfunctionがセキュ リティ機能そのもの、もしくはセキュリティ機能を含む場合、「このよう な操作は望ましくない」といった観点でユースケースが示されることはな い。一方、セキュリティ機能の妥当性を分析する場合、望ましくない操作 等（いわゆる脅威）に対抗するための防御策としての効果と、ビジネス上 の目的を実現する機能としての合理性、利便性、実現可能性（コスト効果 を含む）とのバランスが重要である。そのため、誰が引き起こすどのよう な脅威を想定するのか、また各セキュリティ機能はどの脅威に対して対抗 すると認められるのかの関係を、モデル上で分析することを考える。また ここでは、分析の成果として、2.2節で説明したCC認証制度の取得に必 要となるセキュリティターゲット（ST）作成を目標として説明する。ST 作成を目標とすることにより、脅威（threat）、TOEのセキュリティ対策 方針（objective）、及び評価のターゲットとすることが明示されたセキュ リティ要件の関係から成るセキュリティの構造を明らかにすることがで きる。
4.2
フェーズ１：前提となるセキュリティに関する問題意識
ここでは、ユースケースに対してdataの中で保護すべき資産を保護資産 （asset）とする。また、assetとした際に想定するthreatを定義し、threat からassetを保護する為に有効と想定されるセキュリティ機能（security function）を定義する。この際、マーケティングの結果、特定のシステム （または製品）に対して公知の攻撃手段等、市場が求めているfunctionを 導く「考慮すべきthreat」として定義する部分、企画において市場への訴 求効果のある技術を「実装すべきsecurity function」として定義する部分 など、企画段階・設計上流段階におけるコンセプト設計を反映したモデル ができる。メタモデルにすると図 7フェーズ1のメタモデル図となる。
図7: フェーズ1のメタモデル図
の要素に関連している。例えばセキュリティに関する特定の機能（security function）は、特定の悪意のある行為（threat）から保護すべき何らかの 資産（asset）を保護する為に作られているはずである。どの要素をきっ かけに記載してもよいが、必ず関連する他の2要素が想定できるはずで ある。このフェーズでのリンクは完全である必要は無いが、CC認証制度 を考慮した場合、要素が孤立するようであれば、それはSTに記載する要 素では無く、図からも削除するべきである。このフェーズはSTに記載し ようとしている機能の意味を整理するフェーズであると言える。なお本 フェーズの分析により、CC認証制度のSTの1章へ記述に対応した材料 が揃うことになる。
表1: 基本用語の説明
機能（function） TOEに含めようと考えている機能 資産（asset） 機能により保護される対象データ 脅威（threat） 想定していた資産への不正
セキュリティ機能 functionの中でassetを保護する為の機能、 (security function) security functionにより利用されるasset
4.3
フェーズ２：課題定義と対策
フェー ズ ２ で は 、フェー ズ １ で 洗 い 出 し た security function、asset、 threat を 用 い て 図 8 の メ タ モ デ ル に 従 い 分 析 を 行 う。こ の フェー ズ で は簡単の為にfunctionは図示しなくても良い。ここでは基本的に以下の ステップを繰り返し、分析する。なお以下のステップはどこから始めても よく特に順番は無い。
表 2: フェーズ２のプロセス
ステップ１ threatに対するobjectiveを記述し、そのobjective を満たしているsecurity function、及び対抗して いるthreatに接続する
ステップ2 objectiveにより新たなsecurity functionやassetが 必要となった場合記述する。
ステップ3 assetに対し新たならthreatを想定した場合、記述し assetに接続する。
このサイクルの中で、threatに対してTOEで実装している(実装を予 定している)機能での対策が困難である場合、環境のセキュリティ対策方針 （operational environment) を記述する。また、企業のセキュリティ方針 (policy)を想定する場合は、policyをthreatと同等に扱い（threatと異な り対策することにより新たなpolicyが想定される事は無いが）objective、 もしくはoperational environmentにより対策する。
上記のサイクルを繰り返し新たな要素が出てこなくなった段階で本フェー ズは終了となる。この段階で、operational environmentによってのみ対 策しているthreatは、前提条件(assumption)として記述する。本フェー ズが終了した段階でSTの全体像を掴む為に必要であると言われる4章ま でが記述可能である。
4.4
フェーズ
3
：セキュリティ機能要件
図8: フェーズ2のメタモデル図
認証を求めるobjectiveであれば、CCパート2のFIAクラスの中から識 別（FIA UIDファミリ）及び認証（FIA UAUファミリ）の中から、この objectiveを満足する主となる機能コンポーネントとなるSFRを選ぶ。CC パート2にカタログされた各SFRは、そのSFRとセットでメカニズムを 構成する傾向がある他のSFRが示されている（CCでは「依存性」とい う）。また、依存性の規定はなくても、このSFRで扱う属性やデータを管 理するために通常セットで定義するSFRなども参照できる。これらの参 考情報や、他製品のSTに示されたSFR群のサンプルなどを参考として、 objectiveを満たすために構成すべきSFRのセットを抽出していく。SFR 抽出の段階でobjectiveを満たすために十分なSFRが無い場合は、通常の ST作成と同様に新たにSFRを定義し5章に記述する必要がある。SFRの セットでobjectiveが十分満たされること、過度な要件となっていないこ とについては、SFRセットで期待される効果と制約（及び制約により新た に引き起こされる脅威や脆弱性がないこと）を検討し、コスト的にも妥当 であることを確認する。SFR抽出の結果、そのSFRを実現するsecurity functionについて、当初想定した security function の見直しが必要とな ることもある。その場合は、図9のメタモデルのsecurity function を修 正し、関連するassetへの影響や、新たなthreatへの影響をモデル上で確 認することが必要であり、釣り合いの取れたモデルとなるまでブラッシュ アップを図っていく。
表3: フェーズ２の用語
TOEのセキュリティ threatやpolicyに対する対抗策の方針 対策方針（objective） security functionにより実現可能な範囲
で記述
環境のセキュリティ threatやpolicy、assumptionに対する 対策方針 対抗策の方針TOEの機能ではなく、 (operational 運用等で対抗する方針を記述
environment)
組織のセキュリティ 組織の規定等で、運用やセキュリティ 対策方針（policy） 強度が定義されているものを記述 前提条件 運用や環境の前提条件によりthreatに (assumption) 対応するものを記述。 operational
environmentによる実現が必要
図9: フェーズ3のメタモデル図
4.5
具体的な例
CC認証実績の多い複合型プリンタ（MFP：Multi Function Peripheral）
[4] のセキュリティ文書印刷機能（Security Print Function）という機能
表4: フェーズ３の用語
セキュリティ機能要件 (SFR) security functionにより実現され、 objectiveを実現するために十分 である機能要件
図10: Security Print Function phase 1
他の利用者に盗み見られる可能性や、他の印刷物に紛れ込む可能性を排除 することができる。
• フェーズ1この例ではsecurity functionはfunctionそのものが上記 の様にセキュリティ機能を有している為、特にあらたに考察するこ となくsecurity functionとしてfunctionと同様の名前で定義する。 （なお識別のためにF.PRINTを付加している）。assetは「画像ファ
イル」だが識別の為にsecure print fileとする。また上記説明からセ キュリティ文書パスワードというデータも存在することが解るが、 ここでは分析を想定して、単純に機能で保護するassetとそのthreat であるセキュリティ文書の不正入手のみを記載する（図10）。
ではなく前提条件（assumption）として定義する。STに記述する 際はassetにより排除される（そもそも想定されない）threatは記 述しない。次に、不正なセキュリティ文書パスワードの入手という threatに対して、objectiveによりパスワード規制を設け対応してい るが、例えばTOE外であるクライアントPCへのパスワード入力が 平文であった場合の除き見や、ログインしたまま席を離れた場合の パスワードの盗聴や不正な変更に対応できない。そういったTOEの 機能ではそもそも十分に対策できないthreatに対して、operational environmentを記述し対策する。フェーズ2が終了した時点で、全 てのthreatやpolicy、及びassumptionに対して必ず一つ以上の対 策が接続されているはずである。
またこの段階で、想定したThreatに対抗する為に、F.PRINTには以 下の機能の実装、及び運用環境での対策が必要であることが確認できる。
• secure print fileへのアクセスにはパスワードによる認証が必要であ ること。
• パスワードは強固な値（桁数、ロック機構、文字種等）しか設定で きないこと。
• パスワード入力時に入力文字を隠蔽するアプリケーションを用いる こと。
• ログイン中の離席時には必ずログアウトする運用を徹底すること。
この情報を元に、開発へのフィードバック、ガイダンスへのフィードバッ クを行うことも考えられる。
図11: Security Print Function phase 2
図12: Security Print Function phase 3
4.6
従来方法との比較
前章で提案した分析手順を用いることにより、CC認証制度に伴う 評価 機関による評価に対して、以下のメリットがある。
表5: SFRの説明 SFR CCのガイドライン上の説明
FIA AFL.1 認証失敗時の取り扱いは、利用者の不成功の認証試行が 特定した数になった後、セション確立プロセスを終了で きることを要求する。また、セション確立プロセスの終 了後、その試行が行われた利用者アカウントあるいはエ ントリポイント(例えば、ワークステーション)を、管理 者定義の条件になるまでTSFが無効にできることも要 求される。
FIA UAU.7 保護された認証フィードバックは、認証の間、限定され たフィードバック情報だけが利用者に提供されること を要求する
FMT MTD.1 TSFデータの管理は、許可利用者がTSFデータを管理す ることを許可する。
FIA UAU.2 アクション前の利用者認証は、TSFがその他のアクショ ンを許可する前に、利用者の認証を要求する。
FIA UID.2 アクション前の利用者識別は、TSFがその他のアクショ ンを認める前に、利用者が自分自身を識別することを要 求する。
4.6.1 5.1. フェーズ１及びフェーズ２におけるメリット
CEMに記載されたチェックポイントのうち、フェーズ２までに関係す る主なチェック項目のうち以下に関して、提案方式の図により満たされて いることを比較的容易に確認できる。開発者の立場に立てば、提案方式に 従い作成した図を持ちうることにより、下記ポイントが満たされたSTを 作成できると言える。
• TOE及び／または運用環境によって対抗する必要がある脅威を記 述すること
• 全ての脅威は、脅威エージェント、資産、有害なアクションの観点 から記述すること
• セキュリティ対策方針（TOE、運用環境）が明確に識別されている こと
• 運用環境のセキュリティ対策方針が脅威、組織のセキュリティ対策 方針、前提条件までさかのぼれることを確認すること
• 脅威にさかのぼるセキュリティ対策方針（TOE、運用環境）が必要 であること
• 組 織 の セ キュリ ティ対 策 方 針 に さ か の ぼ る セ キュリ ティ対 策 方 針 （TOE、運用環境）が必要であること
• 前提条件にさかのぼるセキュリティ対策方針（TOE、運用環境）が 必要であること
但し、以下の点については、提案方式の図から完全に把握することは既 存の方式と同様に困難であり今後の検討課題である。
• 脅威にさかのぼるセキュリティ対策方針（TOE、運用環境）が十分 であること。
• 組織のセキュリティ方針にさかのぼるセキュリティ対策方針（TOE、 運用環境）が十分であること。
• 前提条件にさかのぼるセキュリティ対策方針（TOE、運用環境）が 十分であること。
4.6.2 フェーズ３におけるメリット
フェーズ3においても以下のチェックポイントに対して提案方式はメリッ トがある。
• 各SFRがTOEのセキュリティ対策方針にまでさかのぼれること
• どのコンポーネントがSFRを提供するか
• 依存するSFRを提供する、もしくは提供しない場合の理由を明確 にすること
さらに評価機関の立場に立った場合、評価の際のチェックポイントに対 するメリットがある。つまり、例えば評価機関が評価の際に提案方式の図 を確認することにより（図の内容がSTに正直に写されているかの確認は 必要となるが）評価作業が効率化され評価に必要な時間が短縮できること が考えられる。
5
比較研究
ユースケース図をセキュリティに対して拡張した研究例は多く、我々の 提案方式はそれらに大いに依存している。McDermottと Foxによる ア ビューズケース図（Abuse case Diagrams) [6] においては、通常のユース ケースに加えて、インタラクションの結果がシステムに対して害がある ユースケースをアビューズケースと呼んでいる。
SindreとOpdahlによるミスユースケース図[10]においては、ミスユー スケース（Misuse case）とミスユーザ（Misuser）というアクターが明示 的に導入されている。攻撃者とは意図的にシステムに対して害を為す者 という定義に従うと、ミスユーザは、不注意にシステムに害を為す場合 が含まれるので、意味としては広義である。SindreとOpdahl [10] にお いては、ミスユーザとミスユースケースは、色による区別が行われてお り、我々のアプローチのようにステレオタイプを用いた拡張方法を取って いない。それに対して Firesmith におけるセキュリティユースケース図 （Security Usecase Diagrams) [2]においては、SecurityとMisuseをキー ワードとして用いて、通常のユースケースと区別を行っている。我々はこ れを修正してステレオタイプとして定義したものを利用している。
UMLsec [3] は UML を基にしたセキュアなシステム開発手法であり、 配置図、コラボレーション図、クラス図などの図に関して、様々なセキュ リティに関連する特徴を記述するための拡張がなされている。例えば、 配 置図に対しては、新たにセキュアな通信経路などを導入することで拡張し ている。UMLsec においては、ユースケース図は特に大きな拡張が行われ ていない。主な理由としては、 UMLsec はより設計に近いフェーズでの 利用を目指しており、要求分析レベルでの利用についてはまだ弱いことに 起因すると考えられる。
アクティビティ図に関するセキュリティを意識した拡張としてはSindre によるものがある [9]。
第3著者はセキュリティ要求分析手法に関する講座開発を行った経験が あり、そこでは主に Liuによる i*に基づいた方法論[5] が用いられてい る[11]。
ル化するかを取り扱っており、開発プロセス全体については言及していな い。セキュリティの分野において、開発プロセスについて特に注目したも のとしては、Mead らによる SQUARE がある [7]。SQUARE は開発プ ロセスの定義と、各プロセス毎に最善の実践方法（best practice)を提案 している点において優れている。しかし、各開発プロセスを見ると、我々 が主張する「資産（Asset）」に関する観点が欠けていることが分かる。本 技術レポートの第3著者は、その点を Mead に指摘したことがあり、彼 女は現在、「資産（Asset）」を入れた開発プロセスを SQUAREに導入す ることを検討しているとのことである。
第3著者と第4著者はミスユースケース図に資産（Asset）とセキュリ ティゴールを導入し、それに対するプロセスを提案している[8]。KAOS のようなゴール指向要求分析方法論とミスユースケース図の良い部分を選 択した方法論であると言える。プロセスモデルにおいては、システムに関 するセキュリティゴールとシステムに関するセキュリティゴールを分け、 各々を獲得するためのプロセスを示している。
6
結論
本技術レポートでは，ユースケース図を拡張しCC (Common Criteria) との親和性を高めたセキュリティ要求分析方法について考察し，具体的な 分析手順を提案した．さらに，実際に公開されているSTに記載された特 定の機能に対して，提案方式による分析を行い，STに記載されるレベル に過不足ない項目が洗い出せることを確認した．提案方式を用いることに より，特定のシステムに対してCC認証を視野に入れたセキュリティ効率 的な分析が可能と言える．これは分析手法を用いず文章によるSTを記載 した場合に比較して，STの記載段階，さらには機能追加やCC認証の評 価段階における指摘によるSTの修正が発生した際も，4章で比較したメ リットにより改版が効率良く行えると言える．機能や対策の十分性に関し ては提案方式によるモデル図から機械的に読み取ることは不可能である が，それは今後の検討課題である．
参考文献
[1] Common Criteria for Information Technology Security Evaluation
Version 3.1, Part1, Part2, Part3. August 2006.
[3] Jan J¨urjens. UMLsec: Extending UML for secure systems devel-opment. In Fifth International Conference on The Unified
Model-ing Language (UML 2002), volume 2460 of LNCS, pages 412–425.
Springer, 2002.
[4] Konica Minolta Business Technologies, Inc. bizhub 501 / bizhub 421 / bizhub 361 / ineo 501/ ineo 421 / ineo 361 Control Software Version: 0100-G00-11 (System Controller),
A0R50Y0-1D00-G00-10 (BIOS Controller), October 2008.
[5] L. Liu, E. Yu, and J. Mylopoulos. Security and Privacy Require-ments Analysis within a Social Setting. In International
Confer-ence on Requirements Engineering(RE 2003), pages 151–161. IEEE,
2003.
[6] John P. McDermott and Chris Fox. Using abuse case models for security requirements analysis. InACSAC, pages 55–64. IEEE Com-puter Society, 1999.
[7] Nancy R. Mead and Ted Stehney. Security quality requirements engineering (square) methodology. ACM SIGSOFT Software
Engi-neering Notes, 30(4):1–7, 2005.
[8] T. Okubo, K. Taguchi, and N. Yoshioka. Misuse cases + assets + security goals. In2009 International Conference on Computational
Science and Engineering, pages 424–429, 2009.
[9] Guttorm Sindre. Mal-activity diagrams for capturing attacks on business processes. In Peter Sawyer, Barbara Paech, and Patrick Heymans, editors,REFSQ, volume 4542 of Lecture Notes in
Com-puter Science, pages 355–366. Springer, 2007.
[10] Guttorm Sindre and Andreas L. Opdahl. Eliciting security re-quirements with misuse cases. Requirments Engineering Journal, 10(1):34–44, 2005.
[11] Kenji Taguchi and Yasuyuki Tahara. Curriculum design and methodologies for security requirements analysis. Progress in
